This chapter describes how to use the Boot/Dump Configuration process. This chapter includes the following sections:
Change management is the handling of software and configuration data for an IBM 2212. This involves:
The change management functions are available by entering the boot command at the Boot config> prompt (talk 6), or the service recovery interface should the box be in a condition where the hard file or compact FLASH does not contain viable software (that is, you cannot access talk 6).
The IBM 2212 code and configuration data storage resource is divided into areas called "system banks" (banks for short), each containing a single version of the operational code and any other files pertinent to that release of the code. Up to four configuration files are associated with each bank's software.
The general change management model of the IBM 2212 is to introduce new code and/or configuration data to the system while the system runs at its present level and then activate the changed code or configuration data set later. If for some reason the new code or configuration does not function as expected, you have the ability to revert to the previous version of the configuration.
TFTP is a file transfer protocol that runs over the Internet UDP protocol. This implementation provides multiple, simultaneous TFTP file transfers between an IBM 2212's non-volatile configuration memory, image bank, and remote hosts.
TFTP allows you to:
TFTP transfers involve a client node and a server node. The client node generates a TFTP Get or Put request onto the network. The IBM 2212 acts as a client node by generating TFTP requests from the IBM 2212 console using the Boot config> process tftp command.
The client can transfer a copy of a configuration file or image file stored in the image bank of a server.
The server is any device (for example, a personal computer or workstation) that receives and services the TFTP requests. When the IBM 2212 acts as a server, transfers are transparent to the user. Use the ELS subsystem TFTP message log to view the transfer in progress.
This function is important for situations where the receiving TFTP server has a bug handling the block count wrapping back to zero or having a value of 0x8000. The TFTP protocol requires that a block count be transmitted with every data block. The acknowledgement for that data block carries the block number that was in the data block being acknowledged. The transmitter of the data won't send any more data until it receives an acknowledgement for the last data block sent. Once the receiver of the data sends the acknowledgement it expects to receive a data block with a block count that is one greater than the block count it previously received. This block count is two bytes long.
Some TFTP servers have improperly implemented this as a signed short word (two-byte variable where the high order bit being 1 indicates a negative value) and others as an unsigned long word (four byte variable).
If the amount of data to be transferred is so great that the block count wraps, then depending on how the receiver verifies the block count, it may or may not acknowledge the data. If the receiver uses a signed short, the problem will be experienced when the block count goes from 0x7ffff to 0x8000. If the receiver uses an unsigned long or short, the problem will be experienced when the block count goes from 0xffff to 0x0000. In both cases the block count in the data block will appear to be less than the previously received block count and the receiver gets confused.
The transmitting TFTP on the device will either receive an error packet or time out waiting for the receiver to respond. When this happens, TFTP on the device will realize that the block count had wrapped and will automatically recover by making a write request to the receiver for a new file. The new file name is derived from the original file name. The new file name is derived by overlaying the last two characters of the original file name with two decimal digits. Every time the block count wraps, a new file will be written until all the data has been transferred. Tools like cat can be used at the receiver to concatenate the files.
A patch variable was added so that you can specify the maximum number of blocks to transfer to a file at the receiver. This allows you to tell the device to automatically do a write request for a new file once the number of blocks specified has been sent. Doing this circumvents the automatic recovery described above, speeding up the transfer by avoiding the 5 minute timeout period.
The only values that may be specified for this patch variable are: 0xffff (65535) and 0x7fff (32767).
This patch variable is useful if you know that the receiving server has problems handling the wrap of the block count.
There may be occasions when you may want to load a device on a specific day and time when you will be unavailable. You can configure the device to perform a timed load using the timedload activate command. Other commands allow you to view a device's scheduled load information or cancel a scheduled load. See "Change Management Configuration Commands" for information on these commands.